home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group92c.txt / 000079_icon-group-sender _Thu Nov 12 18:36:19 1992.msg < prev    next >
Internet Message Format  |  1993-01-04  |  2KB

  1. Received: by cheltenham.cs.arizona.edu; Thu, 12 Nov 1992 19:43:36 MST
  2. Date: Thu, 12 Nov 92 18:36:19 -0500
  3. From: isidev!nowlin@uunet.uu.net
  4. Message-Id: <9211122336.AA23580@relay2.UU.NET>
  5. To: uunet!cs.arizona.edu!icon-group@uunet.UU.NET
  6. Subject: Re rationale for sortf()
  7. Status: R
  8. Errors-To: icon-group-errors@cs.arizona.edu
  9.  
  10.  > The sortf() function in Icon V8.7 is defined as:
  11.  > 
  12.  >      sortf(X,i)  Produces a sorted list of the elements of X. The
  13.  >                  results are similar to those of sort(X,i),
  14.  >                  except that among lists and among records,
  15.  >                  structure values are ordered by comparing their
  16.  >                  ith fields.
  17.  > 
  18.  > Can someone explain to me why the second argument to the sortf() function is
  19.  > an integer index of the field in the record to sort on, instead of a string
  20.  > containing the field name?
  21.  
  22. The sortf() function works on lists in addition to records.  It remains
  23. flexible enough to do both by using an integer index.  If you specified
  24. field names with a string you would lose the ability to sort lists of
  25. lists.  I suppose you could overload the second argument so that integers
  26. worked for both types of structures but a string in the context of a list
  27. would generate a run-time error.  Not worth it.
  28.  
  29. You can define tables with field names as key and the record index as value
  30. and just use that in place of field name arguments to sortf().  When you
  31. change record definitions you would have to change tables values.  This
  32. won't help with Idol unfortunately.  Maybe Idol could put extra fields at
  33. the end of records to avoid obscuring known index values?
  34.  
  35. Jerry Nowlin
  36.  
  37.